Release 10.1A: OpenEdge Getting Started:
WebSpeed Essentials

Debugging firewall configurations

After configuring the firewall, you must test the configuration to see if it works. The easiest way to do this is to try to run the WebSpeed application from the Internet. This probably means you must disconnect the test client PC from the internal network and then dial an Internet Service Provider (ISP) to then act as a “real” Internet client.

First, make sure everything works by entering the URL for the application into your Web browser. In most cases this method fails because the firewall configuration omitted one or two ports or a ubroker.properties setting was left unchanged.

For help in tracing the cause of the failure, see the "WebSpeed request round-trip" section to remind yourself what the entire round-trip process is and test each stage one at a time. The error shown by the Messenger (if it worked that far) will lead you to the answer as well.

Note: You might want to use a software tool like Ethereal (http://www.ethereal.com) to allow you to see what packets are traversing the network.

If you are using Microsoft Windows 2000 or later to host the Web server, you might find that UDP or TCP packets are being sent, but they are being ignored by the Web server machine. This can be caused by incorrectly setting the IP Packet filter. All ports used for the firewall access must be allowed in the IP Packet filter. Packet filter settings are addressed in the following pages.

To access the IP Packet Filter settings:

In the Windows Control Panel, choose the Network Connections icon.
Right-click on your LAN connection and select Properties from the pop-up menu. The Local Area Connections Properties dialog box appears:



Choose Properties. The Internet Protocol (TCP/IP) Properties dialog box appears:



Choose Advanced. The Advanced TCP/IP Settings dialog box appears:



Select the Options tab, as shown:



Highlight TCP/IP Filtering in the list and then select the Properties button. The TCP/IP Filtering dialog box appears.
You can set the filter to allow all packets as shown, or you can restrict the ports allowed by adding them into the appropriate areas:



Note: If you must use DNS, then you also must allow UDP port 53 and TCP port 53. For the Web server, you need port 80. For HTTP/S, you need port 443.

Web server access

Can your Web browser access the Web server? Put a test HTML file in the Web server’s root directory to see if you can access it with http://webserver/test.htm. If you can, then delete the test HTML file and move on. If the file does not appear, check to see if the Web server is running.

WebSpeed Messenger

Does the WebSpeed Messenger run? If you get a “WebSpeed error from messenger process (6019)” error message, then the WebSpeed Messenger is running. If not, you should enable the Messenger logging function in ubroker.properties as shown in the excerpt below. The default logging level is 1, which is Errors Only. This setting should suffice to show the issues:

[WebSpeed.Messengers] ... logFile=@{WorkPath}\msgr.log loggingLevel=1 ...

You might have received a Web server internal error. This is usually caused by a Web server misconfiguration related to the “executability” settings for CGI programs. Check your Web server documentation to make sure you have configured it to run your WebSpeed Messenger correctly.

If you use the Messenger Administration tool, you can test the configuration of your WebSpeed application. For more information, see the "Configuring a WebSpeed Messenger" section.

NameServer Access

If the Messenger is working, the next step is to confirm that the NameServer is being accessed. Set the NameServer’s logging level to 3 (Verbose) using the Progress Explorer or by editing ubroker.properties manually. To enable this change, you must stop and restart the NameServer and wait for the WebSpeed broker to inform the NameServer that it is available.

If the NameServer does not know about a service, it cannot direct clients to it. To check the NameServer to see if it knows about the WebSpeed server, use either the Status button in the Progress Explorer, as shown in Figure 4–15, or the code NSMAN -name NS1 -query, as shown in Example 4–5.

Figure 4–15: Checking NameServer access using the Progress Explorer

Example 4–5: Checking NameServer access using NSMAN -name NS1 -query

C:\>nsman -name NS1 -query OpenEdge Release 10.0B as of Tues Apr 27 00:31:00 EDT 2004 Connecting to Progress AdminServer using rmi://localhost:20931/Chimera (8280) Searching for NS1 (8288) Connecting to NS1 (8276) NameServer NS1 running on Host nexus Port 5162 Timeout 30 seconds. Application Service UUID Name Host Port Weight Timeout WS.Sports2000_WS 527a0623fe008210:67d940:f6484c1312:-7d87 WS.Sports2000_WS nexus/192.168.123.121 3055 0 30

Now, try to access the application again. After the error is returned to the WebSpeed Messenger, check the NameServer’s log file. You should see something similar to the following:

Thread-0>(26-Jul-03 18:42:15:107) Request received from 192.168.123.110 2167 for WS.Sports2000_WS. (8201) Thread-0>(26-Jul-03 18:42:15:107) AppService = WS.Sports2000_WS Found = true Number Of Brokers = 1. (8206) Thread-0>(26-Jul-03 18:42:15:107) Response sent to 192.168.123.110

If you do not see the “Request received” in the log file, then the firewall is losing the inbound NameServer request. Otherwise, the outbound request is being lost. After debugging this stage, make sure to reset the logging setting.

Accessing the WebSpeed broker

This time, set the WebSpeed broker’s logging setting to verbose and make the request. You should see something similar to the following (at a time just after the NameServer log entry):

L-3055>(26-Jul-03 18:57:53:816) Received connection:: (8125) C-0001>(26-Jul-03 18:57:53:836) Client connected : . (8533) C-0001>ubWSclientThread.processConnRsp(): ubRsp = 0, getNeedNewConnID() = false C-0001>(26-Jul-03 18:57:53:836) The client C-0001 has disconnected from the broker. (8084) C-0001>(26-Jul-03 18:57:53:836) Client disconnected : . (8534)

If the WebSpeed Messenger error says it could not contact the broker, but the broker log file says it was contacted, then the fault is on the return path. If there is no contact logged in the broker log file, then it did not receive the message. Either of these will point to the firewall rule that was left out or misconfigured.

Accessing the WebSpeed agent

Use the 4GL Trace function to see if the agent received the request. Configuring this feature is covered in OpenEdge Deployment: Managing 4GL Applications.

General notes on debugging

Think through the request process and see what the error messages say. This will lead to the issue most of the time.

Check the log files of the firewall itself. These will show what messages are flowing through it. You will probably have to filter these because a production firewall will have more than just your WebSpeed requests going through it.

Always use a new Web browser window for each test request. Most browsers attempt to speed up requests by caching information. A subsequent test in the same browser window can return cached data instead of the proper results for the new settings. This can also be achieved by using the “Reload” function of the browser. See your browser documentation for information on setting your browser to not use cached copies of pages.